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A ll applications wrestle with the problem of copying 
objects at some point. In the course of some recent 
work, I used a variation ofthecloning approach pub¬ 
lished in the Journal of Object-Oriented Programming 
(JOOP) two years ago. 1 This article will describe two 
extensions! added: 

•Allow for customized behavior after the deep copy 
(#postDeepCopy:); and 

•Provide ability to NOT copy certain instance 
variables. 

j USTCLONINGAROUND 

The JOOP article described an 
implementation of a deep copy that 
can handle arbitrarily deep object 
structures in all three major 
Smalltalk dialects. Circularities are 
handled by keeping track of the 
objects copied in an 
IdentityDictionary. The keys are the original object and 
the values are the copies. 

As the title suggests, I lookatthisarticleasa"subclass" 
of the JOOP article. Just as you wouldn't expect to under¬ 
stand a class without browsing its superclass, you should¬ 
n’t expect to understand this article without having read 
theJOOP article. I’ll present a complete implementation 
in code,* but I won’t cover the concepts from the origi nal 
article. 1 ' 


ing.These are not aggregation relationships. For example, 
an invoice does not own the salesperson. 4 

Consider the instancediagram inthetop half of Figure 
2. 1 Jane Profit might use this existing invoice as the basis 
for creati ng a new one. The bottom half of Figure 2 shows 
the resulting instancediagram, if theJOOP approach had 
been used to copy the invoice. There are two problems 
with this result. The first is that everything is copied when 
what we want is to copy only the objects referenced by 
aggregation relationships. For 
example, what we don't, want is a 
new instance of Jane Profit. 

The second problem is that when 
we copy an i nvoice we want to reset 
the quote to the customer. The 
quote is what the customer actual ly 
pays, and it might be higher or 
lower than the actual cost. 
Determining the quote is up to the 
salesperson. I n this particular case the customer has been 
given a $25 discount on an order for three "blue widgets;" 
however, that doesn’t mean he or she will always get that 
discount. In this application we’ve established the rule 
that all quotes should besetto zero when copies are made. 

After copying, what we actually want is shown in 
Figure 3. 

1 I’m not showing the Customer to Invoice relationship for now. 


We need a cl ass method 
that will traverse the 
superclass chain and collect 
the names of all instance 
vari abl estonot copy. 


EXAMPLE 

Consider the OMT 2 style diagram in Figure 1. Each cus¬ 
tomer containsa collection of invoices. Each invoicecon- 
tains a collection of ordered items. These are aggregation 
or ownershi p 3 relationshi ps. 

Each invoice holds a reference to the customer as wel I 
as to the salesperson that created the invoice. Each 
ordered item holds a reference to the product it is order- 


* I used VisualWorks, but this should work in other dialects if 
you keep in mind the issues raised in the JOOP article. 

t The JOOP article also describes how to implement a deep 
equal, which I don’t cover at all. 



Figure 1. Example Object Model. 
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#POSTDEEPCOPY: 

Of our two problems, resetting the quote is the easier 
oneso let’stacklethat first. Our generic problem is being 
able to have customized behavior after an instance is 
copied. Using the normal Visual Works mechanisms, this 
would be done via #postCopy. The equivalent to this in 
our generic mechanism is a method called 
#postDeepCopy: that is sent to the new instance after the 
deep copy is done. Listing 1 shows the implementation 
of the generic copy mechanism. It’s been factored a little 
differently, but other than #postDeepCopy: this is the same 
code as published in theJOOP article. 

Below would be the implementation of this method 
forOrderedltem: 


postDeepCopy: anObject 

super postDeepCopy: anObject. 
self quote: 0. 

The anObject parameter is the original object. I’ve had no 
cause to use it yet, but I thought this parameter might 
comein handy in certai n cases. For instance, we could use 
#postDeepCopy: as a way to solve the problem with copying 
objects that aren’t owned. After the copy is made, we si im¬ 
ply set the appropriate instance variable to refer back to 
the original object. Below is an example for Invoice: 

postDeepCopy: anObject 

super postDeepCopy: anObject. 
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self salesperson: anObject salesperson 
One problem with this approach is that there could be 
side effects to copying a salesperson object, which we 
want to avoid. Let’s see if we can come up with a better 
approach. 

#DONTCOPYVARS 

For any given object we want only to copy some of its 
instance variables. We have a choice, though. We can cre¬ 
ate a mechanism that forces us to specify what should be 
copied, or that requires us to specify what should NOT be 

Ideally, the vendors should 
standardize on some way of 
speci fying " ownership"and make use 
of it in their copy mechanisms. 

copied. I’ve taken the latter approach because, in prob¬ 
lem domains I’ve been exposed to, it appears that more 
things get copied than not. 

This mechanism will also assume that we can specify 
this information on a class basis. In other words, no 
instanceof I nvoice will ever need to create a new instance 
of Salesperson when it is copied. 

Every cl ass can optionally define a class method called 
#dontCopyVars that answers a collection of the named 
instance variables that should not be copied. Below are 
examples from our object model in Figure 1: 

Invoice cIass»dontCopyVars 
"#(#customer #salesPerson) 

Orderedltem c I ass»d o n t Co py Va rs 
/ '#(#product) 

Customer, Salesperson, and Product would not have to define 
a #dontCopyVars method. 

#ALLDONTCOPYVARS 

In our example wedon’t have to worry about inheritance, but 
most structures aren’t this simple. We need a class method 
that will traverse the superclass chain and collect the names 
of all instance variables to not copy. The code below is pat¬ 
terned after #alll nstVarNames 5 and #accumulatel nstVarNames but, 
takes into account that not every class will implement 
#dontCopyVars: 

Object class»allDontCopyVars 
| vars | 

vars : = OrderedCollection new. 
self accumulateDontCopyVars: vars. 

Wars 

Object class»accumulateDontCopyVars: aCollection 


§ You can find a lot of good solutions if you try to think of how 
your problems are similar to something already in the image. 


self superclass notNil 

ifTrue: [self superclass accumulateDontCopyVars: 
aCollection], 

(self class includesSelector: #dontCopyVars) 
ifTrue: [aCollection addAII: self dontCopyVars]. 

These two methods ensure that every class can answer a 
collection of the instance variables that should not be 
copied. All that’s left is a little bit of code to utilize this 
information during copying. See Listing 2. 

MISCELLANEOUS 

Every object should answer a copy of itself when sent the 
message #copy. Users of the object should not have to 
worry about whether it uses the deep copy mechanism. 
To account for this, I usually redefine #copy for all my 
domain objects as follows: 

copy 

"self deepCopy 

When we copy an invoice we need to know whether we 
are maki ng a copy for use with the customer that owns the 
original invoice, or for a different customer. To handlethis 
I defined a #copyFor: method in Invoice that takes the 
Customer as a parameter: 
copyFor: aCustomer 
I aCopy| 

aCopy : = self copy. 
aCustomer invoices add: aCopy. 
aCopy customer: aCustomer. 

"aCopy. 

Avoid the temptation to specify #dontCopyVars based on the 
current functionality of your application. As an example, 
assume that Orderedltem instances have a reference to thei r 
containing Invoice. Also assume that the application cur¬ 
rently allows Invoices to be copied, but not Orderedltems. 
You might be tempted to not include #invoice in 
#dontCopyVars for Orderedltem. Because of the support for 
circularities in the copy mechanism, if Invoice is copied 
before Orderedltem the Orderedltem will end up pointing to 
the correct Invoice anyway. 

However, at some point these kinds of assumptions 
will come back to haunt you. Every object should be able 
to answer a reasonable copy of itself. 

CONCLUSION 

U nfortu nately, Smal Ital k does not provide a way to disti n- 
guish between aggregation relationships and simple ref¬ 
erences. What I’ve provided is one way of doing this. 
Ideally, the vendors should standardize on some way of 
specifying "ownership” and make use of it in their copy 
mechanisms. This kind of standard would, for example, 
allow CASE vendors to output this information during 
codegeneration. 

LISTING 1 

instance methods in Object 
deepCopy 
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deepCopyWithoutRecopying: anldentityDictionary 
'anldentityDictionary 
at: self 

ifAbsent: [self doDeepCopyWithoutRecopying: 
anldentityDictionary] 

doDeepCopyWithoutRecopying: anldentityDictionary 
I aCopy | 

aCopy : = self shallowCopy. 
aCopy — self ifTrue: ["'self], 
anldentityDictionary at: self put: aCopy. 
self class isPointers ifFalse: [•'aCopy], 
aCopy releaseCopyDependents. 
aCopy copyNamedVarsWithoutRecopying: 
anldentityDictionary. 

aCopy copyllnnamedVarsWithoutRecopying: 
anldentityDictionary. 
aCopy postDeepCopy: self. 


releaseCopyDependents 
'self breakDependents 

copyNamedVarsWithoutRecopying: anldentityDictionary 
| newPart | 

1 to: self class instSize do: 

[: i d x | 

newPart := (self instVarAt: idx) 
deepCopyWithoutRecopying: anldentityDictionary. 
self instVarAt: idx put: newPart], 

copyllnnamedVarsWithoutRecopying: 
anldentityDictionary 
| newPart | 

1 to: self basicSize do: 

[:idx | 

newPart := (self basicAt: idx) 
deepCopyWithoutRecopying: 
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anl dentityDictionary. 

self basicAt: idx put: newPart]. 

postDeepCopy: anObject 

'The receiver is a deeply copied instance of anObject. 
Subclasses may override this method to provide 
behavior after copy is done" 

LISTING 2 

instance methods in Object 

copyNamedVarsWithoutRecopying: anl dentityDictionary 
| newPart | 

self class allVarl ndicesToCopy do: 

[:idx | 

newPart := (self instVarAt: idx) 

deepCopyWithoutRecopying: 
anl dentityDictionary. 

self instVarAt: idx put: newPart], 

class methods i n Object 
allVarl ndicesToCopy 

"Answer a collection of the indices of all named 
variables to copy for the receiver" 

''self allVarNamesToCopy collect: 

[:each | self all I nstVarNames indexOf: each] 

allVarNamesToCopy 

"Answer a collection of all variable names to copy for 
the receiver" 

''self alll nstVarNames reject: 

[:each | self allDontCopyVars includes: (each asSymbol)] 

dontCopyVars 

"Answer a collection of instance variables defined in 
this class that should not be copied when a deep copy is 
made of an instance of the receiver or one of its 
subclasses. The collections should contain symbols, not 
strings. 

Only classes that define instance variables that shouldn't 
be copied need to define this method" 

■'■'#() a 
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